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SYSTEMS AND METHODS FOR SIMULATING GAME STATE 
CHANGES RESPONSIVE TO AN INTERRUPT CONDITION 

5 BACKGROUND OF THE INVENTION 

[01] The present invention relates generally to simulated racing games, and more 
particularly to simulating race statistics and results for portions of a race or a full race or 
responsive to an interrupt condition during a simulated race. 

[02] Yellow Flags (cautions) are a major facet of racing sports such as NASCAR racing. 

10 There are a multitude of strategies and positional changes that result from a yellow flag 

caused by a wreck, spin, or other event. For example, a yellow flag provides an opportunity 
for cars to take pit stops, cars to bunch up, and lapped cars to catch up and become unlapped. 
In simulated racing games, such as NASCAR Thunder™ 2002, Yellow Flag options may be 
provided to enhance the reality of the game to conform with events as would take place in a 

15 real world race (eg,, a NASCAR-sanctioned race). However, in such simulated racing 

games, many people often refrain from activating a Yellow Flag enabling option due to the 
tedium of watching cars pace around the track slowly, e.g., 3 laps or more, during the 
cautionary period. It is therefore desirable to provide racing games that keep the strategy and 
gameplay associated with cautionary events such as would occur with activated Yellow Flag 

20 options, but which allow one to remove the perceived tedium previously associated with such 
game options. 

[03] Further, in current racing games, when participating in a scheduled season, or tuning, 
there is generally no way to progress through the schedule without entering and racing or 
quitting out of each race in the schedule. This can make tuning, or gameplay, a very time 
25 consuming process. It is therefore desirable to provide racing games that allow a user to 
simulate complete races or partial races, for example, to facilitate tuning and/or quick 
progression through a season mode. 

30 BRIEF SUMMARY OF THE INVENTION 

[04] The present invention provides simulation methods that enhance the reaUty of a racing 
game and also reduce perceived tedium associated with interrupt events, for example. 



cautionary events such as Yellow Flag events or user selected interrupts such as race 
termination. The present invention also provides for enhanced full race simulation and partial 
race simulation. In general, as used herein, "interrupt" or "interrupt event" is intended to refer 
to an interrupt condition responsive to a game event that causes an interruption in normal 
5 game play, which may be completely AI generated, completely user generated, or partially AI 
generated and partially user generated, such as a user selection responsive to a computer 
generated event, 

[05] To overcome delays inherent due to Yellow Flag or other cautionary events, the 
present invention provides the player with the ability to skip ahead, yet simulate real life 

10 events that would occur diuing the caution period. The player(s) are not forced to watch the 
entire pace lap when a Yellow Flag or other cautionary event occurs. The most exciting or 
interactive parts are left available to the user (such as the option to pit, or the ability to race 
back to the start/finish line at the onset of a caution in a race such as a NASCAR race), but 
the more tedious parts of the caution event are skipped over and simulated. The user is then 

15 placed in a position to restart the race, and that position is determined by both the actual user 
actions as well as the simulated events that occurred during the cautionary period. A 
simulation module simulates events that may occur during the cautionary period based on, 
e.g.^ current relative position of vehicles, attributes and current statistics for vehicles, whether 
or not other vehicles choose to make a pit stop etc., and compiles new statistics and attributes 

20 that are used in the resumed race. This break in the action also provides an opportunity for 
other features to be presented to the user, to add statistic banners, wreck replays, and 
race recaps without worry about interrupting the race action. 

[06] A fiiU race simulation option and a partial race simulation option are also provided. 
These options are particularly useful for situations where statistics are accumulated for a race 

25 or set of races (e.^., for a season). For example, in a season mode, the person who is tuning 
or playing the season does not have to enter and exit every race on the season schedule in 
order to properly obtain statistics from the races. The present invention is useful for game 
designers creating or tuning races, and for players. For players, the present invention is 
particularly beneficial when a player wants to simulate a race, or portion of a race, because 

30 they don't want to spend the time, or have no interest in a particular race or portion of a race. 
[07] A simulation module simulates events that may occur during a race and compiles 
statistics that can be used later, e.^., in a later race, for season standings, etc. Such statistics 
may include performance related statistics (e.^., lap times, total time, position relative to 
other vehicles, etc.) and attribute information {e.g., aggressiveness of driver, wear of vehicle. 



2 



tires, suspension, etc.). Not only can a complete race be simulated, but a partial simulation of 
a race is also an option. For example, if a player decides to terminate a race before it is 
actually finished, the simulation module can make a determination of the outcome of the race 
using already compiled statistics and the performance of the individual cars in the race up to 
5 that point. This also benefits season statistics tracking and calculation as the generated set of 
data ensures that the season's statistics are intact and properly calculated. Multiple race 
simulations, or multiple season simulations may also be performed in certain aspects. 
[08] A simulation module according to the present invention allows one to simulate the 
next race within a season or a career fi'om the fi'ont end without entering the actual race. The 

10 module preferably has access to all of the information about the vehicles participating in the 
race and their attributes in order to produce appropriate simulation data. Real world statistics 
are imported and used in some aspects. For example, real world standings, performance 
statistics and attribute information are stored in a database and are used as a basis for AI- 
controlled vehicle performance and Al-generated simulation results. 

IS [09] The simulation module is configurable to execute and simulate and compile end of 
race statistics when a player quits out of a race, wrecks out of a race, or wins a race where 
some computer generated (AI generated) vehicles have not visibly finished the race. 
[10] According to an aspect of the present invention, a method is provided for simulating 
game state changes responsive to an interrupt condition in a computer-implemented racing 

20 game. The method typically involves interrupting the normal game state which already has a 
set of statistics associated with it The method then allows for parts of the interrupted game 
state to be simulated in conjimction with possible user interaction, in order to derive an 
updated set of statistics which reflect the results of this interrupted game state. Typically, the 
game state is then retumed to the normal game state or some type of conclusionary game 

25 state such as the end of the race. 

[11] According to another aspect of the present invention, a method is provided for 
simulating game state changes responsive to an interrupt condition in a computer- 
implemented racing game. The method typically includes generating an interrupt condition 
during the racing game at a first game state, the first game state having a first set of statistics 

30 associated therewith, and responsive to the interrupt condition, simulating events that occur 
after the first game state based on the first set of statistics so as to produce a second set of 
statistics associated with a second game state. The method also typically includes resimiing 
the racing game in the second game state. The second game state may be associated with an 
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active state of the race, e.^., before the end of the race, or it may be associated with the end of 
the race. 

[12] According to another aspect of the present invention, a computer readable medium is 
provided that includes code for controlling a processor to simulate game state changes 
S responsive to an interrupt condition during a race in a racing game. The code typically 

includes instructions to retrieve a first set of statistics associated with a first game state from a 
database in response to an interrupt condition, simulate events that occur after the first game 
state based on the first set of statistics so as to produce a second set of statistics associated 
with a second game state, and store the second set of statistics to the data base. The second 

10 game state may be associated with an active state of the race, e.^., before the end of the race, 
or it may be associated with the end of the race. The second or later sets of statistics may be 
stored as files separate from the first set of statistics, or each subsequent statistics file may be 
incorporated with the prior file so that one set of accumulated statistics is stored. 
[13] Reference to the remaining portions of the specification, including the drawings and 

15 claims, will realize other features and advantages of the present invention. Further features 
and advantages of the present invention, as well as the structure and operation of various 
embodiments of the present invention, are described in detail below with respect to the 
accompanying drawings. In the drawings, like reference niunbers indicate identical or 
functionally similar elements. 

20 

BRIEF DESCRIPTION OF THE DRAWINGS 
[14] Figure 1 illustrates a computer system configured with an executable gaming 
application according to an embodiment of the present invention; and 
25 [15] Figure 2 illustrates a client-server arrangement for executing a gaming application 
according to an embodiment of the present invention. 



DETAILED DESCRIPTION OF THE INVENTION 
30 [16] Figure 1 illustrates a client computer system 10 configured with a gaming application 
(application module 40) according to the present invention. Figure 2 illustrates a client- 
server arrangement for executing a shared gaming application according to another 
embodiment of the present invention. Client system 10 may operate as a stand-alone system 
or it may be connected to server 60 and/or other client systems 10 over a network 70. 
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[17] Several elements in the system shown in Figures 1 and 2 include conventional, well- 
known elements that need not be explained in detail here. For example, a client system 10 
could include a desktop personal computer, workstation, laptop, stand-alone game system 
such as a Sony Playstation2™, X-Box™, Nintendo GameCube™, etc, or any other 
S computing device capable of executing gaming application module 40. In client-server or 
networked embodiments, a client system 10 is configured to interface directly or indirectly 
with server 60, e.^., over a network 70, such as the Internet, or directly or indirectly with one 
or more other client systems 10 over network 70. Client system 10 typically runs a browsing 
program, such as Microsoft's Intemet Explorer, Netscape Navigator, Opera or the like, 

10 allowing a user of client system 10 to access, process and view information and pages 

available to it from server system 60 or other server systems over Intemet 70. Client system 
10 also typically includes one or more user interface devices 30, such as a keyboard, a mouse, 
touchscreen, pen or the like, for interacting with a graphical user interface (GUI) provided on 
a display 20 {e.g., monitor screen, LCD display, etc.). In preferred aspects, user interface 

15 device 30 includes a mouse, joystick, steering wheel, gas pedal, force-feedback controller, or 
other game-specific controller. Speakers are also provided for audio feedback. Multiple user 
interface devices may be provided for concurrent use by multiple users such as in a 
multiplayer mode. 

[18] In one embodiment, application module 40 executes entirely on client system 10, 
20 however, in some embodiments the present invention is suitable for use in networked 
environments, e,g.y client-server, peer-peer, or multi-computer netwoiked environments 
where portions of code may be executed on different systems. Interconnection via the 
Intemet is preferred, however, it should be imderstood that other networks can be used 
instead of the Intemet, such as an intranet, an extranet, a virtual private network (VPN), a 
25 non-TCP/IP based network, any LAN or WAN or the like. 

[19] According to one embodiment, client system 10 and some or all of its components are 
operator configurable using gaming application module 40, which includes computer code 
executable a central processing unit 50 such as an Intel Pentium processor or the like coupled 
to other components over one or more busses 54 as is well known. Computer code including 
30 instructions for operating and configuring client system 10 to process game and data content, 
simulate race events and statistics, and render images as described herein is preferably stored 
on a hard disk, but the entire program code, or portions thereof, may also be stored in any 
other volatile or non- volatile memory medium or device as is well known, such as a ROM or 
RAM, or provided on any media c£q)able of storing program code, such as a compact disk 
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(CD) medium, digital video disk (DVD) medium, a floppy disk, and the like. An appropriate 
media drive 42 is provided for receiving and reading data and code from such a computer- 
readable medium. Additionally, the entire program code of module 40, or portions thereof, 
may be transmitted and downloaded from a software source, e.g., from server system 60 to 
5 client system 10 or from another server system or computing device to client system 10 over 
the Internet as is well known, or transmitted over any other conventional network connection 
{e.g., extranet, VPN, LAN, etc) using any communication medium and protocols (e.g., 
TCP/BP, HTTP, HTTPS, Ethernet, etc.) as are well known. It should be understood that 
computer code for implementing aspects of the present invention can be implemented in a 

10 variety of coding languages such as C, C-f+, Java, Visual Basic, and others, or any scripting 
language, such as VBScript, JavaScript, Perl or markup languages such as XML, that can be 
executed on client system 10 and/or in a client server arrangement. In addition, a variety of 
languages can be used in the extemal and internal storage of data, e.g., statistics information, 
according to aspects of the present invention. 

15 [20] According to one embodiment, a game application (represented as module 40) 
executing on client system 10 includes instructions for implementing a racing game, 
including simulations as described herein. Application 40 is preferably downloaded and 
stored in a hard drive 52 (or other memory such as a local or attached RAM or ROM), 
although appUcation module 40 can be provided on any software storage medium such as a 

20 floppy disk, CD, DVD, etc. as discussed above. In one embodiment, iq>plication module 40 
' includes various software modules for processing data content, such as a communication 
interface module 47 for communicating text and data to a display driver for rendering images 
on display 20, and for receiving user input signals from user input device 30. Application 
module 40 also includes a simulation module 45 including instructions to simulate race 

25 events and related statistics using compiled statistics and attribute information as discussed 
herein. Compiled statistics, attributes and other information are preferably stored in database 
55, which may reside in memory 52, in a memory card or other memory or storage system, 
for retrieval by simulation module 45. It should be appreciated that application module 40, or 
portions thereof, as well as appropriate data can be downloaded to and executed on client 

30 system 10. 

[21] In the client-server arrangement of Figure 2, portions of game module 40 may execute 
on client 10 while portions may execute on server 60. For example, a game module shell 
may execute on client 10 with periodic data, e.g.^ vehicle positional and statistical 
information, updates provided to and from server 60. Similarly, in a networked environment. 
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updates may be provided between computers, such as in a multi-player mode over the 
Intemet. 

[22J In preferred aspects, application module 40 implements a simulated vehicle racing 
game, such as an auto race, bicycle race or motorcycle race, boat race or jet ski race, 
5 snowmobile race, etc. It should be appreciated that other racing games may be implemented, 
such as dog races, horse races or track and field type races, in which case, a living body is 
typically a user-controlled or computer-controlled 'Vehicle". One or more vehicles may be 
controlled by one or more users, and one or more vehicles may be controlled by the conlputer 
(AI controlled vehicles). 

10 [23] Typically, the simulated race is conducted on a course or a track requiring one or 

more laps and/or passing required checkpoints. Various viewpoints are typically provided to 
the user on the display during the course of the race. For example, portions of the course and 
other vehicles may be displayed fi-om the viewpoint of the user's vehicle, from above, and 
from a point along the course. Additionally, various other display elements may be 

15 concurrently displayed, or altemately displayed as a different window at the request of the 
user. Such display elements include performance statistics and elements such as speed 
indicators, speed, average lap time, e/c, vehicle attributes such as fuel level indicators, 
fatigue, temperature and pressure indicators, etc., and other display elements as may be 
suitable for simulating a real-life racing environment. 

20 [24] The present invention will now be described with reference to an auto race, such as a 
NASCAR-sanctioned type race, although the present invention is applicable to other races as 
mentioned above. 

[25] In NASCAR racing, a vehicle is required to make multiple laps to complete the race. 
During the race, it is typically necessary to make pit stops, for example to refuel, change or 

25 take on new tires, etc. Additionally, during the race, cautionary events such as wrecks, spin- 
outs, debris on the track, e^c, may take place based on, for example, a user input that causes 
or contributes to the event, or Al-generated events. Typically a Yellow Flag is shown to the 
racers during such a cautionary event, and a pace car enters the field to pace the cars during 
the cautionary event. Cars may make pit stops, catch up to the rest of the pack or maintain 

30 their present positions as desired or as strategy dictates. 

[26] For added reality, cautionary events are added to the gameplay of the present 
invention. For example, activation of a **Yellow Flag" option allows the computer to 
simulate cautionary events as well as the resulting **Yellow Flag" p^iod. 
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[271 According to one embodiment, a user selectable "Quick Cautions" option is added to 
modify or supplement the "Yellow Flag" option. When selected, the "Quick Cautions" 
option allows the user to skip through much or all of the cautionary event period yet simulate 
events that occur during the period. For example, a user may select to make a pit stop to 
S refuel, and then is placed back in an appropriate position to restart/resume the race after the 
pit stop based on Al-generated position changes occurring during the cautionary period. 
[28] An example process flow will now be described with reference to examples of visual 
display characteristics and control characteristics and functions presented to the user. 
According to one embodiment, an example of a "Quick Cautions" flow proceeds as follows: 

10 

1) Yellow Flag event occurs 

[291 Visual: Regular racing view with waving yellow flag indicator. 

[30] Control: Regular racing controls until the player crosses the line, unless player stops, 

significantly slows, or turns around. 

15 

2) Player crosses the start/finish line 

[31] Visual: Track/demo cameras focused on the player car or track/demo cameras 
focused on the start finish line. 
[32] Control: No player control, 

20 [33] Function: The order of cars lining up correctly will be simulated behind the scenes . 
The cars will start to line up normally until 2a) occurs. At that point, any remaining 
movement necessary in to line-up the cars for pacing is simulated when the transition to 3) 
occurs. Fuel and tire wears are preferably used on a per lap basis, e.g.y if a decision to pit is 
made and before a restart occurs. Fuel usage is simulated on a per lap basis, regardless of 

2S whether a decision to pit is made or not. Also, in some situations (e.^., short races) fuel 
usage is not calculated. 

2a) S seconds after last player crosses the start/finish line 

[34] Visual: Track/demo cameras focused on pace car leaving pit road or track/demo 
30 cameras focused on the pace car pulling out in front of the line of cars on the backstretch. 
[35] Control: No player control. 

[36] Function: After the last player crosses the line, the cars are ordered as they were 
when they crossed the line. Lapped cars are mixed in where they crossed the line. 



3) After Pace car pulls out 

137] Visual: Track/demo cameras focused on the player. Cars in a single-file line led by 
the pace car on the back stretch. A Tit Under Caution?' pop-up or other selectable option is 
displayed. The player's remaining fuel, tires, and damage meters are preferably shown. 
5 [38] Control: Select *Yes' or *No' using controller, e.g., D-Pad and X (A for Xbox). 

[39] Function: The cars are lined up as in 2a). A pop-up is presented indicating whether or 
not the player wants to make a pit stop. The player has until the pop-up is scheduled to go 
away in order to decide to pit. If the player hasn't made a decision, it is taken as *No.' If 
there are cars in fi-ont of the player, they begin to enter the pit row (if they decide to pit or a 
10 decision is made for them to pit) before the pit query is dismissed. If the player selects No, 
they are taken to 5a) after a set time, e.g., 2 seconds. In multiplayer mode, wait until every 
player has made a decision. 

4) Decision is made to pit. 

15 [40] Visual: Cars continuing to pace and entering pit road using Track/demo cameras 

focused on the player. A Pit Options menu is preferably displayed, including, e.g., options to 
refuel, replace tires, etc. - 

[41] Control: The player uses a controller, e.g., D-pad and X to make selections on the Pit 
Options menu. 

20 [42] Function: The player is preferably presented with the Pit Options menu as soon as 
they enter pit road. In multiplayer mode, if all players select Abort, the flow immediately 
moves to 5a). The Pit Options menu remains on the screen until a selection is made. Then it 
is taken away and the currently selected option(s) are used. If a Fuel Use mode is set to ON, 
the amount of fiiel remaining in the cars is decreased by the amount of fuel it takes to run the 

25 entire caution period. However, the player's fiiel cannot go below zero - their car will be 
considered as having successfully coasted to pit road. 

5) Pit Stop 

[43] Visual: Car entering pit stall with cameras fi-om side or driver's view. A pit timer is 
30 preferably presented. Al-controUed cars that made the decision to pit (as determined by 
simulation module 45 based on statistics and attributes for that car) are preferably made 
visible moving down pit road or in their stall depending upon their place in the caution line 
and pit row. After the stop is finished, the car is shown exiting its pit stall. 
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[44] Control: No player control 

[45] Function: The pit stop proceeds with camera cuts and audio. After the car is shown 
exiting its pit stall, the flow moves to 5a). In multiplayer mode, the lead car's pit stop is 
preferably presented in a single window. 

5 

5a) Fuel Check 

[46] Function: At this point, a transition occurs from the Pit Stop (or pace) stage back to 
the Resume/Restart stage of the flow. Once again, the amount of fuel available to the player 
(if a Fuel Use mode is set to ON) is decreased in order to represent the amoimt of fuel which 
1 0 would actually be used during the remainder of the caution period. 

6) Resume/Restart 

[471 Visual: Similar to race start. The camera is preferably in the player's driving view 
and the countdown is given. Pace car is already gone or is shown leaving. 

15 [48] Control: Player has regular race countdown controls. 

[49] Function: The cars are lined up and ready to start. The current lap is updated to 
reflect the number of caution laps that were 'run.' If pitting has occurred, position swaps 
have probably occurred as determined by simulation module 45. For example, cars who did 
not pit are moved in front of cars who pitted maintaining their relative initial caution 

20 positions. Cars who pitted are ordered behind them in order of pit stop speed. In order to 
keep the 43"* car from getting in front of the 1*' car during pitstops, for example, some time 
based upon a car's position is added to the pitstop time. Lapped cars are lined up on the 
inside, unless the restart is occurring with 10 or less laps to go. In that case, they are 
positioned at the end of the line. 

25 

Finish Race Under Caution 

[50] In certain aspects, a race is allowed to finish under caution if the number of laps 
remaining is equal to or less than the number of caution laps. For example, if there is only 

30 one lap remaining, a view of the pace car leading the cars across the start/finish line is 

presented after 3). If there are more than 2 laps remaining, proceed as normal until step 6). 
At that point, the same view of the pace car leading the cars across the start/finish line as 
above is presented. In other aspects, the race is not allowed to finish under caution. In this 
aspect, the pace Is^s are not counted, nor is a calculation of fuel consumption and tire use 

35 made. 
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[52] Exemplary embodiments of full and partial race simulations follows: 
Full Race and Partial Race Simulation; 

5 

[53] In one embodiment, a full race simulation tool is provided. The tool is preferably 
accessed from within the front end of the game, for example, from a setup screen, or within a 
season mode configuration screen. In this embodiment, simulation module 45 retrieves all of 
the necessary driver statistics and attribute information (aggressiveness, control, e/c), vehicle 

10 statistics information (e.g., wear, average speed, etc.), so that it can provide a sensible 
simulation of the next race. For example, where a user has selected to model some or all 
competitors' cars, or their own car on real-world race cars and drivers, the application uses 
real world statistics and attributes taken from real world races. For example, real-world 
statistics and attributes data may be provided with the game application or as separate 

15 modules provided on a computer-readable medium, downloaded over a network, 

input/modified by a user, etc., and stored in the database. Thus, for Al-controUed cars, the 
simulation module retrieves statistics from the database for simulating events that occur 
during the race. For simulation of user-controlled cars, the simulation module retrieves 
statistics based on past races, if any, or randomly generated statistics. 

20 [54] A variety of weighting schemes may be appUed to the retrieved statistics, e.g., to 

determine frequency of cautionary events based on driver aggressiveness and control values, 
relative performance based on past performance scores and attributes, etc. The simulation 
module generates a final set of statistics for the race, each car, and/or each driver, the results 
may be displayed explicitly as a table of results or, preferably as a summary of events that 

25 occurred, including for example, order of finish, total lap times, crashes, etc. The simulation 
module updates the database with all of the necessary race statistics, which are used to 
calculate season standings, break ties, determine awards winners, as well as all other 
information that is required to progress through a season. In this manner, the simulation 
results closely tie in with what a user may expect to see within a race that was actually run. 

30 [55] In one embodiment, a partial race may be simulated. For example, a user may select 
to simulate the beginning of a race and take over control of a car near the end of the race, a 
user may select to have an intermediate portion of the race simulated (e.g., "Quick Cautions" 
mode), or a user may choose to interrupt a game and quit out of a partially completed race, 
but have the race finish nonetheless, for example, for maintaining a database of compiled race 

35 statistics for a season. 
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[56] For any simulation mode (Full or Partial Race, or Quick Cautions), the simulation 
module closely approximates what would happen within a race, e.g., during a cautionary 
period or if it were to continue until all driving cars cross the line under a checkered flag 
based upon the AI characteristics. The simulation proceeds similar to the full race simulation 
S described above. As above, the module retrieves statistics for participant cars and generates 
all of the necessary events (passing, yellow flags, crashes, pit stop decisions, etc.) that are 
used to calculate the post-simulation statistics. When simulating the beginning of a race, the 
post simulation statistics are used to position cars for the user to complete the race; for a user 
quitting out of a race, the post-simulation statistics are recorded to the database for use in 

10 standings and/or a later race. The database is appropriately updated with the necessary end 
race statistics are used within the &ont end to calculate awards, season rankings, etc, 
[57] During any simulation mode the simulation module preferably generates mistakes for 
the Al-controUed cars, randomly and/or based on history information, driver attributes such 
as aggressiveness, current game condition of car attributes such as suspension and braking 

15 characteristics, track profile and characteristics, weather characteristics, etc. The simulation 
code generates random wrecks for the simulated drivers. The result of the random wrecks 
would reflect that the driver wrecked out of the race and any other information that is 
normally recorded for a wrecked car. 

[58] In one embodiment, the simulation results are dumped to a file so that they can be 
20 viewed before any calculations are performed on the data. This is not necessary to the design 
but it may prove to be a valuable tool, e.^., to allow a user to approve of simulation results 
before being recorded. 

[59] While the invention has been described by way of example and in terms of the 
specific embodiments, it is to be understood that the invention is not limited to the disclosed 
25 ^bodiments. To the contrary, it is intended to cover various modifications and similar 
arrangements as would be apparent to those skilled in the art. Therefore, the scope of the 
appended claims should be accorded the broadest interpretation so as to encompass all such 
modifications and similar arrangements. 

30 
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